OpenTSDB

1. OpenTSDB 소개

1.1 OpenTSDB 개요 및 핵심 목표

OpenTSDB(Open Time Series Database)는 Hadoop 및 HBase 생태계 위에서 동작하도록 설계된 분산형, 확장 가능한 시계열 데이터베이스(Time Series Database)이다.1 시스템의 핵심 목표는 대규모 시계열 데이터를 세분성(granularity)의 손실 없이 영구적으로 저장하고 조회할 수 있는 플랫폼을 제공하는 것이다.2 이를 위해 초당 수백만 건에 달하는 쓰기 작업을 처리할 수 있는 높은 처리량을 목표로 설계되었으며, 데이터는 밀리초(millisecond) 수준의 정밀도로 원시 상태 그대로 영구 보존하는 것을 기본 철학으로 삼는다.2

1.2 개발 배경 및 설계 철학

OpenTSDB는 본래 StumbleUpon에서 자사의 대규모 분산 시스템—네트워크 장비, 운영체제, 애플리케이션 등—에서 발생하는 방대한 양의 메트릭을 효과적으로 수집, 저장 및 시각화할 목적으로 개발되었다.5 이는 하루에 10억 개 이상의 데이터 포인트를 안정적으로 저장해야 하는 실제적인 운영 요구사항에서 비롯된 것이다.6 이러한 탄생 배경은 OpenTSDB의 아키텍처와 설계 철학 전반을 규정한다. 즉, 쿼리 언어의 풍부함이나 데이터 모델의 유연성보다는 HBase의 특성을 최대한 활용하여

쓰기 처리량과 확장성을 최우선으로 고려하는 방향으로 진화했다. 이는 대규모 실시간 모니터링 시스템이라는 초기 사용 사례에서 ’읽기’보다 ‘쓰기’ 성능이 압도적으로 중요했기 때문이며, 당시 가장 확장성 있는 쓰기 저장소였던 HBase를 채택하는 자연스러운 결과로 이어졌다.

1.3 Hadoop 및 HBase 생태계 내에서의 위치

OpenTSDB는 독립적인 데이터베이스 시스템이라기보다는, 이미 검증된 분산 시스템인 Hadoop과 HBase 위에 구축된 애플리케이션 계층으로 이해해야 한다.1 데이터의 영구 저장, 분산 처리, 일관성 유지, 고가용성 보장과 같은 데이터베이스의 핵심적인 기능은 전적으로 HBase에 의존한다.3 이러한 HBase에 대한 깊은 의존성은 OpenTSDB의 가장 큰 장점인 대규모 확장성을 가능하게 하는 동시에, 운영의 복잡성이라는 단점을 야기하는 핵심적인 양면적 특성이다. OpenTSDB의 설계는 ’어떻게 하면 HBase에 가장 효율적으로 시계열 데이터를 쓸 수 있는가?’라는 질문에 대한 해답이며, 이는 현대의 많은 시계열 데이터베이스들이 추구하는 ’어떻게 하면 데이터를 유연하게 분석할 수 있는가?’라는 질문과는 다른 출발점을 가진다.

2. 시스템 아키텍처

2.1 핵심 구성 요소

OpenTSDB의 아키텍처는 세 가지 주요 구성 요소로 이루어져 있다.6

• Time Series Daemon (TSD): TSD는 데이터의 입출력을 담당하는 핵심 데몬 프로세스다. 각 TSD는 독립적으로 실행되며 서로 상태를 공유하지 않는(stateless) 마스터 없는(masterless) 아키텍처를 채택하고 있다.7 이 설계 덕분에 부하 분산 장치 뒤에 TSD 인스턴스를 추가하는 것만으로 간단하게 시스템을 수평적으로 확장할 수 있다. 사용자는 Telnet 스타일 프로토콜, HTTP API, 또는 내장된 간단한 GUI를 통해 TSD와 통신한다.7
• Data Collectors: 각 모니터링 대상 서버에 배포되어 운영체제나 애플리케이션 등에서 메트릭을 주기적으로 수집하여 TSD로 전송하는 에이전트 역할을 수행한다. StumbleUpon에서 개발한 tcollector가 대표적인 예시다.6
• Storage Backend (HBase / Google Bigtable): 수집된 시계열 데이터의 영구 저장을 담당하는 백엔드 저장소다. 기본 저장소는 HBase이며, 모든 데이터 포인트는 기본적으로 tsdb라는 이름의 단일 대규모 테이블에 저장된다.1

2.2 데이터 흐름 분석 (Write/Read Path)

데이터가 시스템에 저장되고 조회되는 경로는 다음과 같이 분석할 수 있다.

• 쓰기 경로 (Write Path):

1. tcollector와 같은 데이터 수집기가 메트릭을 수집하여 TSD로 전송한다.
2. TSD는 수신된 데이터 포인트의 메트릭 이름과 태그들을 tsdb-uid 테이블에서 조회하여 고유 ID(UID)를 확인하거나, 새로운 항목일 경우 UID를 할당한다.
3. 할당된 UID와 타임스탬프를 조합하여 HBase에 저장될 Row Key를 생성한다.
4. 생성된 Row Key와 측정값을 HBase에 저장(Put)한다. 이 과정은 일반적으로 비동기 HBase 클라이언트(AsyncHBase)를 통해 효율적으로 처리된다.10

• 읽기 경로 (Read Path):

1. 사용자는 HTTP API를 통해 조회할 메트릭, 시간 범위, 태그 필터, 집계 함수 등을 명시한 쿼리를 TSD로 전송한다.
2. TSD는 쿼리를 분석하여 HBase에서 스캔해야 할 Row Key의 시작과 끝 범위를 계산한다.
3. HBase에서 해당 범위의 데이터를 스캔하여 관련된 모든 데이터 포인트를 가져온다.
4. TSD는 HBase로부터 가져온 대량의 원시 데이터를 메모리 상에서 집계(aggregation), 보간(interpolation), 다운샘플링(downsampling)과 같은 연산을 수행한다.
5. 최종적으로 처리된 결과를 사용자에게 반환한다.

2.3 분산 및 확장성 설계

OpenTSDB의 확장성은 TSD와 HBase 두 계층에서 이루어진다. TSD는 상태를 공유하지 않으므로, 쓰기 부하가 증가하면 단순히 TSD 인스턴스를 추가하여 선형적으로 처리 용량을 늘릴 수 있다.2 마스터 노드가 존재하지 않아 단일 장애점(SPOF)이 없는 구조다.

실질적인 데이터의 분산, 복제, 확장성은 전적으로 HBase에 위임된다. HBase는 테이블 데이터를 리전(Region)이라는 단위로 자동 분할하고, 이를 클러스터 내의 여러 리전 서버(RegionServer)에 분산시켜 저장한다.5 따라서 데이터가 증가하더라도 HBase 클러스터에 노드를 추가하는 것만으로 전체 저장 용량과 처리 성능을 확장할 수 있다.

이러한 TSD의 stateless 아키텍처는 쓰기 확장성을 극대화하는 데 매우 효과적이지만, 읽기 성능의 병목 지점을 두 곳으로 분산시키는 결과를 낳는다. 읽기 요청은 TSD가 HBase로부터 대량의 원시 데이터를 가져와 메모리 내에서 CPU 집약적인 연산(집계, 다운샘플링 등)을 수행해야 하는 복잡한 작업이다.12 따라서 읽기 성능은 첫째, HBase가 얼마나 빨리 데이터를 스캔하여 TSD에 전달하는가, 둘째, TSD가 그 데이터를 얼마나 빨리 처리하는가에 의해 결정된다. 특히 넓은 시간 범위나 높은 카디널리티를 가진 쿼리는 HBase에 과도한 스캔 부하를 유발하고 13, TSD에는 메모리 부족(OOM) 오류를 유발할 수 있다.12 이는 OpenTSDB가 ‘쓰기에 최적화된’ 시스템이며, ’읽기’는 부차적인 고려사항이었음을 보여주는 구조적 증거라 할 수 있다.

3. 데이터 모델 및 스키마 설계

3.1 데이터 모델의 4대 요소

OpenTSDB에 저장되는 모든 데이터 포인트는 네 가지 핵심 요소로 구성된다.4 이 모델은 Prometheus와 같은 현대적인 모니터링 시스템에서도 유사하게 채택되었다.16

• Metric: 측정 대상의 이름을 나타내는 문자열이다 (예: sys.cpu.user). 메트릭 이름은 가능한 한 일반적인 것으로 유지하고, 구체적인 대상(서버, 인터페이스 등)은 태그로 구분하는 것이 권장된다.17
• Timestamp: 데이터가 측정된 시점을 나타내는 Unix epoch 시간이다. 초 또는 밀리초 단위의 정수 값을 사용한다.4
• Value: 측정된 실제 수치 값이다. 64비트 정수 또는 단정밀도 부동소수점 값을 지원한다.7
• Tags: 데이터를 설명하고 구분하기 위한 하나 이상의 키-값(key-value) 쌍이다 (예: host=web01, dc=lga). 모든 데이터 포인트는 최소 하나 이상의 태그를 가져야 한다.4

3.2 태그 기반 다차원 모델링과 카디널리티(Cardinality)

태그는 OpenTSDB 데이터 모델의 핵심적인 특징으로, 데이터를 다차원적으로 분리하고 그룹화하는 강력한 수단을 제공한다.7 동일한 메트릭(sys.cpu.user)이라도 태그 조합({host=web01, dc=lga}, {host=web02, dc=lga})이 다르면 각각 별개의 고유한 시계열(time series)로 취급된다.

이때 **카디널리티(Cardinality)**는 특정 메트릭에 대해 존재할 수 있는 고유한 시계열(즉, 태그 값 조합)의 총 수를 의미한다.4 예를 들어, host 태그가 1000개의 값을, dc 태그가 5개의 값을 가질 수 있다면, 이 두 태그만으로도 카디널리티는 5000에 달한다. 높은 카디널리티(예: 사용자의 IP 주소나 요청 ID를 태그 값으로 사용하는 경우)는 UID(고유 ID) 할당 공간의 고갈 및 심각한 쿼리 성능 저하라는 두 가지 문제를 야기한다.4 일반적으로 OpenTSDB는 메트릭당 시계열 수가 약 1만 개를 넘어서면서부터 쿼리 성능 저하가 눈에 띄게 나타나기 시작하는 것으로 알려져 있다.14

3.3 HBase 스키마 심층 분석

OpenTSDB는 HBase의 특성을 최대한 활용하기 위해 고도로 최적화된 스키마를 사용한다. 주요 테이블은 tsdb와 tsdb-uid이다.

• tsdb 데이터 테이블:

모든 시계열 데이터 포인트가 저장되는 핵심 테이블이다.9 이 테이블의 설계는 OpenTSDB의 성능 특성을 결정하는 가장 중요한 요소다.

• Row Key 구조: Row Key는 [salt]<metric_uid><base_timestamp><tagk1_uid><tagv1_uid>... 형태의 바이트 배열로 구성된다.9 이 구조는 HBase가 Row Key를 기준으로 데이터를 사전순으로 정렬하여 저장하는 특성을 활용하여, 관련 데이터를 물리적으로 가깝게 배치함으로써 조회 성능을 높이도록 설계되었다.

• Salt: 특정 메트릭에 대한 쓰기가 짧은 시간 동안 집중될 경우, HBase의 단일 리전 서버에 부하가 몰리는 ‘핫스팟(hotspot)’ 현상이 발생할 수 있다. Salt는 Row Key의 가장 앞에 해시 기반의 짧은 접두사를 추가하여, 동일한 메트릭의 데이터라도 여러 다른 리전으로 분산시켜 쓰기 부하를 균등하게 만든다.[9]

• Timestamp Normalization: Row Key에 저장되는 타임스탬프는 실제 타임스탬프가 아니라, 시간 단위(기본 1시간)로 정규화(normalized)된 값이다. 예를 들어, 08:15, 08:30, 08:55에 발생한 데이터는 모두 08:00을 나타내는 동일한 기본 타임스탬프를 Row Key에 갖게 된다. 이는 한 행에 너무 많은 데이터 컬럼이 생성되는 것을 방지하고, 시간 기반 범위 스캔을 효율적으로 만든다.[9]

• Column Qualifier: 실제 데이터 포인트의 정확한 시간 정보는 Row Key의 기본 타임스탬프로부터의 시간 차이(offset)로 변환되어 컬럼 한정자(Column Qualifier)에 인코딩된다. 예를 들어, 기본 타임스탬프가 1292148000이고 실제 데이터 포인트 시간이 1292148123이라면, 오프셋 123이 컬럼 한정자에 저장된다. 이는 Row Key의 전체 크기를 줄여 스토리지 효율성을 높이는 중요한 최적화 기법이다.[9]

• tsdb-uid 테이블:

tsdb-uid 테이블은 메트릭, 태그 키, 태그 값과 같은 긴 문자열들을 짧은 고정 길이의 고유 ID(UID)로 상호 변환하는 매핑 정보를 저장한다.5

id 컬럼 패밀리는 문자열 -> UID 정방향 매핑을 저장하고, name 컬럼 패밀리는 UID -> 문자열 역방향 매핑을 저장한다.9

새로운 문자열에 대한 UID 할당은 HBase가 제공하는 원자적 증가(atomic increment) 연산을 통해 이루어져 동시성 문제를 해결한다.9

이러한 HBase 스키마 설계는 ’시간적 지역성(temporal locality)’과 ’시계열 지역성(time series locality)’을 극대화한다. HBase는 Row Key 순서대로 데이터를 저장하므로, Row Key가 metric_uid로 시작하고 그 뒤에 timestamp가 오는 구조는 동일한 메트릭의 데이터가 시간 순서대로 물리적으로 연속되게 저장되도록 보장한다. 그 결과, ’특정 메트릭의 특정 시간 범위’를 조회하는 쿼리(예: web01 서버의 지난 1시간 CPU 사용량)는 HBase에서 매우 효율적인 단일 범위 스캔(range scan)으로 처리될 수 있다.

하지만 이 설계는 태그 기반의 광범위한 필터링 쿼리에는 본질적으로 비효율적이다. 예를 들어, ’dc=lga 태그를 가진 모든 시계열’을 조회하는 쿼리를 생각해보자. dc=lga에 해당하는 tagv_uid는 Row Key의 뒷부분에 위치하며, 각 시계열의 metric_uid가 모두 다르기 때문에 해당 데이터들은 HBase의 여러 다른 위치에 흩어져 저장된다. 이러한 쿼리를 처리하기 위해 OpenTSDB는 잠재적으로 테이블의 매우 넓은 영역을 스캔해야 하므로 성능이 급격히 저하된다.3 이는 스키마 설계가 특정 유형의 쿼리(drill-down)에는 고도로 최적화되어 있지만, 다른 유형의 쿼리(slice-and-dice)에는 구조적으로 취약하다는 한계를 명확히 보여준다.

4. 핵심 메커니즘 분석

4.1 UID 및 TSUID 할당 시스템

• UID (Unique Identifier): OpenTSDB는 메트릭, 태그 키, 태그 값과 같은 모든 문자열 이름을 각각 고유한 정수 ID(UID)로 변환하여 저장한다. 기본적으로 3바이트 크기를 가지며, 이는 저장 공간 효율을 극대화하기 위한 핵심적인 최적화 기법이다.20 예를 들어, sys.cpu.user.nice와 같은 긴 문자열을 매번 저장하는 대신 3바이트 UID만 저장함으로써 스토리지 공간과 네트워크 전송량을 획기적으로 줄일 수 있다.3

• UID 할당: 새로운 문자열이 포함된 데이터가 TSD에 처음 수신되면, TSD는 먼저 내부 캐시에서 해당 UID를 조회한다. 캐시에 없는 경우, tsdb-uid 테이블의 전용 카운터 행에 HBase의 원자적 증가(atomic increment) 연산을 요청하여 새로운 UID를 할당받는다.9

• TSUID (Time Series Unique Identifier): TSUID는 특정 시계열을 고유하게 식별하는 ID로, Row Key에서 타임스탬프 부분을 제외한 <metric_uid><tagk1_uid><tagv1_uid>...의 조합으로 구성된다.20 이 TSUID는 시계열에 대한 메타데이터를 관리하거나 특정 시계열을 직접 참조할 때 유용하게 사용된다.21

• UID의 한계: 기본 3바이트 UID 체계는 각 타입(메트릭, 태그 키, 태그 값)당 최대 약 1,677만(224) 개의 고유 항목만 허용한다는 명백한 한계를 가진다.4 이는 태그 값의 종류가 매우 다양한 고카디널리티 환경에서는 잠재적인 제약 조건이 될 수 있다.

4.2 데이터 처리 및 쿼리

OpenTSDB는 원시 데이터를 조회하는 과정에서 의미 있는 정보를 추출하기 위해 집계와 다운샘플링이라는 두 가지 핵심적인 데이터 처리 메커니즘을 제공한다.

• 집계 (Aggregation):

집계는 쿼리 조건과 일치하는 여러 시계열을 수학적 연산을 통해 하나의 시계열로 병합하는 과정이다.23 OpenTSDB 쿼리는 반환될 시계열이 하나일지 여러 개일지 미리 알 수 없으므로, 항상 집계 함수를 명시해야 한다.23

• 보간 (Interpolation): 집계 과정에서 중요한 개념은 보간이다. 서로 다른 시계열은 데이터 포인트의 타임스탬프가 정확히 일치하지 않는 경우가 많다. 이때 한 시계열에는 특정 타임스탬프에 값이 있지만 다른 시계열에는 값이 없는 경우, 누락된 값을 추정하기 위해 보간이 사용된다. OpenTSDB는 기본적으로 두 지점 사이를 직선으로 잇는 선형 보간(linear interpolation)을 사용하여 누락된 값을 계산한다.8

• 다운샘플링 (Downsampling):

다운샘플링은 데이터의 해상도를 의도적으로 낮추어 시각화의 가독성을 높이고 쿼리 성능을 향상시키는 기법이다.8 예를 들어, 1초 단위로 수집된 데이터를 1시간 단위의 평균값으로 변환하여 장기간의 추세를 쉽게 파악할 수 있다.

• 다운샘플링은 간격(Interval)(예: 1h for 1 hour)과 집계 함수(Aggregation Function)(예: avg for average)를 지정하여 수행된다.25

• 버전 2.3부터는 월, 주, 일과 같이 달력의 경계에 맞춰 다운샘플링을 수행하는 기능이 추가되어, 비즈니스 리포팅과 같이 인간의 시간에 기반한 분석에 매우 유용하다.25

• 롤업 및 사전 집계 (Rollups & Pre-Aggregates):

초기 OpenTSDB 설계는 모든 쿼리가 HBase에서 원시 데이터를 스캔하여 실시간으로 집계 및 다운샘플링하는 것을 가정했다. 이 방식은 유연하지만, 데이터 양이 많아지면 TSD와 HBase에 엄청난 부하를 주어 서비스 불안정성을 야기했다.13 이러한 읽기 성능 문제를 해결하기 위해 버전 2.4에서 롤업 및 사전 집계 기능이 도입되었다.2

• Rollup: 단일 시계열을 시간 축에 따라 미리 다운샘플링하여 저해상도 데이터를 별도로 저장하는 것이다.15 예를 들어, 1분 단위 원본 데이터와 함께 1시간 단위 합계 데이터를 미리 만들어 둔다.

• Pre-Aggregate: 높은 카디널리티를 가진 메트릭에 대해, 여러 시계열을 특정 태그 기준으로 미리 집계하여 저장하는 것이다.9 예를 들어, 수천 개 서버의 CPU 사용률을 데이터센터별 합계로 미리 계산해 둔다.

이 기능들의 도입은 쿼리 시점의 연산 부하를 쓰기 시점이나 별도의 배치 작업 시점으로 옮기는 전형적인 데이터웨어하우징 최적화 기법이다. 이는 OpenTSDB가 단순한 데이터 저장소를 넘어 분석 플랫폼으로서의 역할을 수행하려는 진화의 증거다. 하지만 중요한 점은, OpenTSDB는 이러한 롤업 데이터 생성을 자동화하지 않으며, 사용자가 외부에서 별도의 스트림 처리나 배치 작업을 통해 롤업 데이터를 생성하고 OpenTSDB에 다시 저장해야 한다는 것이다.13 이는 롤업 구현의 복잡성을 사용자에게 전가한다는 한계를 명확히 보여준다.

5. 운영 및 관리

5.1 명령줄 인터페이스 (CLI)

OpenTSDB는 컴파일 후 생성되는 tsdb 셸 스크립트를 통해 다양한 관리 및 운영 도구를 제공한다.26

• tsd: TSD 데몬을 시작하는 가장 기본적이고 일반적인 명령어다.26
• uid: tsdb-uid 테이블을 직접 조작하고 관리하는 유틸리티다. 특정 이름에 할당된 UID를 조회하거나, UID에 해당하는 이름을 찾는 lookup 기능, 새로운 이름에 UID를 할당하는 assign, 기존 UID의 이름을 변경하는 rename 등의 하위 명령어를 제공한다.27
• fsck: tsdb-uid 테이블의 데이터 정합성을 검사하고 복구하는 매우 중요한 도구다. 예를 들어, 정방향 매핑(name -> UID)과 역방향 매핑(UID -> name)이 일치하지 않는 데이터 손상 상태를 찾아내고 수정할 수 있다.27
• query, scan, import: CLI 환경에서 직접 데이터를 쿼리하거나(query), HBase 테이블을 로우 레벨에서 스캔하거나(scan), 파일로부터 대량의 데이터를 가져오는(import) 작업을 지원한다.26

UID 시스템은 성능을 위해 엄격한 정합성 검사를 일부 포기하는 대신, fsck와 같은 사후 복구 도구를 제공한다. TSD 비정상 종료나 네트워크 문제로 인해 UID 할당 과정에서 오류가 발생하면, tsdb-uid 테이블의 정방향 매핑과 역방향 매핑이 불일치하는 상태가 될 수 있다.27 이 경우 특정 UID를 가진 데이터는 존재하지만 그 UID가 어떤 이름에 해당하는지 찾을 수 없어 쿼리가 실패하게 된다.20

fsck는 이러한 ‘깨진’ 상태를 사후에 스캔하고 복구하기 위해 만들어졌다. 이는 시스템이 완벽한 ACID를 보장하기보다는 최종적 일관성(eventual consistency)에 가까운 모델로 동작하며, 운영자는 이러한 잠재적 문제를 인지하고 주기적으로 시스템 상태를 점검해야 할 책임이 있음을 시사한다.

5.2 설정 및 최적화

OpenTSDB의 주요 동작은 opentsdb.conf 설정 파일을 통해 제어된다.28

• tsd.core.auto_create_metrics: 이 값이 false(기본값)로 설정되면, 사전에 mkmetric CLI 등으로 생성되지 않은 새로운 메트릭 이름이 포함된 데이터 포인트는 거부된다. 운영 환경에서는 의도하지 않은 메트릭(오타 등)이 무분별하게 생성되는 것을 방지하기 위해 false로 유지하는 것이 권장된다.28
• HBase 관련 설정 (tsd.storage.hbase.\*): HBase 클러스터에 접속하기 위한 ZooKeeper 쿼럼 주소(zk_quorum), 데이터 테이블(data_table), UID 테이블(uid_table) 이름 등을 설정한다.10
• UID 관련 설정 (tsd.storage.uid.width.\*): 메트릭, 태그 키, 태그 값에 대한 UID의 바이트 크기를 기본 3바이트에서 변경할 수 있다. 단, 이 설정은 데이터가 없는 새로운 OpenTSDB 설치 시에만 변경 가능하며, 기존 시스템에서는 변경할 수 없다.4

5.3 플러그인 아키텍처

OpenTSDB 2.0부터 도입된 플러그인 프레임워크를 통해 TSD의 핵심 기능을 확장할 수 있다.29

• Search Plugin: UID 메타데이터나 주석(annotation)을 ElasticSearch와 같은 외부 검색 엔진으로 실시간 전송하여, 태그나 설명에 기반한 복잡한 시계열 검색을 가능하게 한다.29
• RPC Plugin: 기본적으로 지원하는 Telnet 및 HTTP 프로토콜 외에, Google Protobufs나 Apache Thrift와 같은 다른 RPC 프로토콜을 통해 데이터를 수신할 수 있도록 확장한다.29
• Authentication Plugin: TSD로 들어오는 모든 요청에 대해 사용자 정의 인증 로직을 추가하여 보안을 강화한다.29
• Startup Plugin: TSD가 시작되거나 종료되는 시점에 특정 로직(예: 서비스 디스커버리에 등록)을 수행하도록 할 수 있다.29

6. 종합 평가 및 비교 분석

6.1 장점 (Advantages)

• 대규모 확장성: Hadoop과 HBase라는 검증된 분산 시스템 위에 구축되어, 클러스터에 노드를 추가하는 것만으로 손쉽게 수평적 확장이 가능하다. 이를 통해 초당 수백만 건의 쓰기 작업을 처리할 수 있다.2
• 높은 스토리지 효율성: 긴 문자열 메트릭과 태그를 짧은 고정 길이 UID로 대체하고, HBase의 행 압축(Row Compaction) 및 LZO와 같은 범용 압축 알고리즘을 통해 데이터 포인트당 저장 공간을 2-3바이트 수준으로 최소화한다.6
• 데이터 모델의 유연성: 태그 기반의 스키마리스(schemaless) 데이터 모델은 모니터링 대상이 변경되거나 새로운 측정 차원(태그)이 추가될 때, 데이터베이스 스키마를 변경할 필요 없이 유연하게 대응할 수 있다.
• 검증된 안정성: StumbleUpon, Stack Overflow 등 대규모 프로덕션 환경에서 오랜 기간 사용되며 그 안정성과 성능이 검증되었다.6

6.2 단점 (Disadvantages)

• 운영의 복잡성: HBase 클러스터 자체의 설치, 운영, 튜닝은 상당한 전문 지식과 경험을 요구한다. 이는 OpenTSDB 운영의 가장 큰 진입 장벽이자 높은 유지보수 비용의 원인이 된다.3
• 제한적인 쿼리 언어: SQL이나 PromQL과 같이 표현력이 풍부한 쿼리 언어가 부재하다. 단순한 집계와 필터링은 가능하지만, 여러 메트릭 간의 연산이나 복잡한 분석 쿼리를 수행하기는 매우 어렵다.31
• 높은 카디널리티 처리 문제: 고유한 시계열의 수가 많은(high cardinality) 메트릭에 대한 쿼리 성능이 급격히 저하되며, 3바이트 UID 공간이 고갈될 위험이 존재한다.4
• 늦게 도착하는 데이터(Late-Arriving Data) 처리의 어려움: 데이터가 발생 시간과 무관하게 지연되어 시스템에 도착하는 경우, 특히 롤업과 같은 사전 집계 데이터를 정확하게 생성하는 것이 매우 복잡하다.13

6.3 주요 시계열 데이터베이스와의 비교

OpenTSDB는 ‘2세대’ 시계열 데이터베이스의 대표 주자로, 그 설계는 현대의 ‘3세대’ TSDB(Prometheus, InfluxDB 등)와 비교할 때 명확한 시대적 차이를 보인다. 이 차이는 주로 기술 패러다임이 ‘데이터 저장’ 중심에서 ‘데이터 분석 및 운영 편의성’ 중심으로 전환된 것에서 비롯된다. OpenTSDB가 설계될 당시의 주요 과제는 ’폭발적으로 증가하는 시계열 데이터를 어떻게 안정적으로 저장할 것인가’였고, HBase는 이 문제에 대한 최적의 해답이었다. 그 후 등장한 Prometheus, InfluxDB 등은 이미 대규모 데이터 저장이 어느 정도 해결된 상황에서 ’저장된 데이터를 어떻게 더 쉽고, 빠르고, 유연하게 분석하고 활용할 것인가’라는 다음 단계의 문제에 집중했다. 이로 인해 3세대 TSDB들은 더 표현력 있는 쿼리 언어, 쉬운 설치와 운영, 높은 카디널리티 데이터에 대한 더 나은 지원과 같은 특징을 갖게 되었다.32

• vs. Prometheus: Prometheus는 단일 노드로 시작하여 운영이 매우 간편하며, 강력한 쿼리 언어인 PromQL을 제공하는 것이 가장 큰 차이점이다.32 반면 OpenTSDB는 처음부터 분산 시스템을 전제로 하므로 운영이 복잡하지만, HBase를 통해 대규모 수평 확장이 용이하다.
• vs. InfluxDB: InfluxDB는 태그 외에 ’필드(fields)’라는 개념을 도입하여 다중 값 저장을 지원하고, 문자열이나 불리언 등 다양한 데이터 타입을 지원한다.32 또한 상용 클러스터링 옵션과 관리형 클라우드 서비스를 제공하여 운영 부담을 줄여준다.33
• vs. VictoriaMetrics: VictoriaMetrics는 특히 높은 카디널리티 데이터 처리와 쿼리 성능 면에서 OpenTSDB보다 월등한 성능을 보이며, 더 높은 데이터 압축률을 제공한다.14 PromQL과 호환되는 쿼리 언어를 지원하여 분석의 유연성 또한 뛰어나다.

7. 적용 사례 및 결론

7.1 주요 활용 분야

OpenTSDB의 아키텍처적 특성은 다음과 같은 분야에서 그 강점을 발휘한다.

• 대규모 IT 인프라 모니터링: 수만 대 이상의 서버, 네트워크 장비에서 발생하는 대량의 메트릭을 중앙에서 안정적으로 수집하고 장기간 보관하는 데 적합하다.34
• 산업 데이터 로깅 (IoT): 공장 설비, 스마트 그리드 센서 등에서 끊임없이 생성되는 대용량 시계열 데이터를 비용 효율적으로 저장하는 용도로 활용될 수 있다.35
• 금융 시장 데이터 저장: 주가, 거래량 등 고빈도로 발생하는 금융 데이터를 원본 그대로 장기간 아카이빙하는 데 사용될 수 있다.35

7.2 실제 도입 사례 분석

• StumbleUpon: 개발사로서 자사의 대규모 서비스 모니터링 시스템의 핵심 데이터 저장소로 OpenTSDB를 성공적으로 활용했다.6
• Stack Overflow: 널리 알려진 모니터링 시스템인 Bosun의 백엔드 데이터 저장소로 OpenTSDB를 사용했다.30

이러한 사례들은 OpenTSDB가 대규모 쓰기 부하를 안정적으로 처리하는 데 강력한 역량을 가지고 있음을 증명한다. 그러나 동시에 이들 사례에서는 높은 카디널리티 문제나 쿼리 성능의 한계로 인해 Google Bigtable과 같은 다른 솔루션으로의 전환을 검토하기도 했다는 점은 주목할 만하다.30 이는 OpenTSDB의 강점과 약점이 실제 운영 환경에서 어떻게 나타나는지를 잘 보여준다.

7.3 결론

OpenTSDB는 대규모 시계열 데이터의 ’저장’이라는 시대적 과제에 대해, HBase라는 강력한 분산 시스템을 기반으로 매우 효과적이고 확장성 있는 해결책을 제시한 선구적인 시스템이다. UID를 통한 스토리지 최적화와 stateless TSD를 통한 쓰기 확장성 설계는 오늘날에도 여전히 기술적으로 높이 평가할 만한 가치가 있다.

그러나 HBase 운영의 본질적인 복잡성, 표현력이 제한된 쿼리 능력, 그리고 높은 카디널리티 데이터 처리의 구조적 한계는 Prometheus, InfluxDB, VictoriaMetrics와 같은 현대적인 시계열 데이터베이스에 비해 명백한 약점으로 작용한다.

최종적으로, OpenTSDB는 다음과 같은 특정 시나리오에서 여전히 유효한 선택지가 될 수 있다:

1. 이미 조직 내에 Hadoop/HBase 생태계에 대한 깊은 투자와 운영 전문성을 보유하고 있는 경우.
2. 쿼리 유연성이나 복잡한 분석보다는, 대규모 데이터의 안정적인 수집 및 장기 저장이 비즈니스의 최우선 요구사항인 경우 (예: 대규모 레거시 인프라 모니터링, 규제 준수를 위한 데이터 아카이빙).

하지만 새로운 시계열 데이터 기반 프로젝트를 시작하는 경우, 운영 편의성, 강력한 분석 기능, 그리고 더 나은 성능을 제공하는 최신 시계열 데이터베이스를 우선적으로 고려하는 것이 대부분의 상황에서 더 합리적인 결정일 것이다.

8. 참고 자료

1. Using OpenTSDB, https://guide.ncloud-docs.com/docs/en/hadoop-chadoop-use-ex1
2. OpenTSDB - A Distributed, Scalable Monitoring System, https://opentsdb.net/
3. A Comprehensive Analysis of Open-Source Time Series Databases …, https://www.alibabacloud.com/blog/a-comprehensive-analysis-of-open-source-time-series-databases-1_594730
4. Writing Data — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/writing/index.html
5. Chapter 7. HBase by example: OpenTSDB - Hbase in Action - liveBook · Manning, https://livebook.manning.com/book/hbase-in-action/chapter-7/
6. OpenTSDB - Database of Databases, https://dbdb.io/db/opentsdb
7. A Distributed, Scalable Monitoring System - OpenTSDB, https://opentsdb.net/overview.html
8. Understanding OpenTSDB — A distributed and scalable Time …, https://medium.com/analytics-vidhya/understanding-opentsdb-a-distributed-and-scalable-time-series-database-e4efc7a3dbb7
9. HBase Schema — OpenTSDB 2.4 documentation, http://opentsdb.net/schema.html
10. OpenTSDB integration with kerberized HBase - Stack Overflow, https://stackoverflow.com/questions/44412563/opentsdb-integration-with-kerberized-hbase
11. OpenTSDB Metric HBase Region Finder - Salesforce Engineering Blog, https://engineering.salesforce.com/opentsdb-metric-hbase-region-finder-cf3d55c79565/
12. Time Series Database:Advantages over OpenTSDB - Alibaba Cloud, https://www.alibabacloud.com/help/en/time-series-database/latest/advantages-over-opentsdb
13. Roll up to speed up: Improving OpenTSDB query performance | by Skyscanner Engineering, https://medium.com/@SkyscannerEng/roll-up-to-speed-up-improving-opentsdb-query-performance-83a647cba4ac
14. VictoriaMetrics vs. OpenTSDB | Blg, https://blg.robot-house.us/posts/tsdbs-grow/
15. Rollup And Pre-Aggregates — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/rollups.html
16. Data model - Prometheus, https://prometheus.io/docs/concepts/data_model/
17. Definitions — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/definitions.html
18. Understanding Metrics and Time Series — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/query/timeseries.html
19. FAQ - OpenTSDB - A Distributed, Scalable Monitoring System, https://opentsdb.net/faq.html
20. UIDs and TSUIDs — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/uids.html
21. Metadata — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/metadata.html
22. Quick Start — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/quickstart.html
23. Aggregators · OpenTSDB Documents, https://cgqfzy.gitbooks.io/opentsdb-documents/chapter8.html
24. Aggregation — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/query/aggregators.html
25. Downsampling — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/query/downsampling.html
26. CLI Tools — OpenTSDB 2.4 documentation, http://opentsdb.net/cli.html
27. uid — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/cli/uid.html
28. Configuration File - OpenTSDB 2.4 documentation, http://opentsdb.net/docs/build/html/user_guide/configuration.html
29. Plugins — OpenTSDB 2.4 documentation, https://opentsdb.net/docs/build/html/user_guide/plugins.html
30. OpenTSDB backed by BigTable : r/devops - Reddit, https://www.reddit.com/r/devops/comments/aigshz/opentsdb_backed_by_bigtable/
31. Is OpenTSDB the correct choice? - Google Groups, https://groups.google.com/g/opentsdb/c/E35-lhPOvh4
32. Comparison to alternatives | Prometheus, https://prometheus.io/docs/introduction/comparison/
33. Compare Popular Databases - InfluxDB, https://www.influxdata.com/comparison/
34. Open TSDB Integration - Nobl9, https://www.nobl9.com/integrations/open-tsdb
35. Unlock Efficient Data Storage with OpenTSDB Technology - Tribes Digital, https://tribes.agency/technologies/opentsdb/
36. 16 Time Series Database Use Cases Across Sectors [2024] - Timeplus, https://www.timeplus.com/post/time-series-database-use-cases